Added listener-side support bits for QUIC connection migration#9
Added listener-side support bits for QUIC connection migration#9mishtak00 wants to merge 1 commit into
Conversation
|
It looks like |
| if path?.hasMigrationInfo == true { newPath.pathHasMigrationInfo = true } | ||
| multiplexingPaths[newPath.identifier] = newPath | ||
| if !isFirstPath { | ||
| handlePathChanged(path: newPath.identifier, event: .available, isPrimary: newPath.pathIsPrimary) |
There was a problem hiding this comment.
Why is the event .available ? Shouldn't it be .established?
Why are we only sending an event when it's not the first path?
There was a problem hiding this comment.
As it stands, .available gets fed to QUICConnection.handlePathChanged(.available), which calls path.changeState(to: .routeAvailable) and invokeEstablish(), which calls connect(). The .established event does beginValidation(), which is further down the line for migration. Are you suggesting we wiggle this state wiring a bit?
As for why not first path too, initialPath has a different treatment. See QUICConnection.swift:1291. From my understanding, first path is a different concept from primary path. How could we even kick off migration if the target path is the first path? Or are you saying we'd be migrating back to the initial path from a sojourn?
There was a problem hiding this comment.
Well, available just means that the system told us we can attach a lower protocol to it. Here you are attaching a lower protocol already, so I thought it would be .established.
1c7796f to
b5489f0
Compare
3 participants
hasMigrationInfoflag onPathPropertiesand wired it inManyToManyProtocolattachLowerDatagramProtocolForNewPath